<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="generator" content="pandoc">
  <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
  <title>前端进阶指南 – </title>
  <style type="text/css">code{white-space: pre;}</style>
  <link rel="stylesheet" href="style.css">
  <!--[if lt IE 9]>
    <script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script>
  <![endif]-->
  <meta name="viewport" content="width=device-width">
</head>
<body>
<p>
<h1>前端进阶</h1>
<p>Phodal</p>
</p>
<div style="width:800px">
<nav id="TOC">
<ul>
<li><a href="#前端进阶指南">前端进阶指南</a><ul>
<li><a href="#什么是前端">什么是前端</a></li>
<li><a href="#本书内容">本书内容</a></li>
</ul></li>
<li><a href="#硬技能篇">硬技能篇</a></li>
<li><a href="#前端知识要点">前端知识要点</a><ul>
<li><a href="#前端应用的生命周期">前端应用的生命周期</a><ul>
<li><a href="#入门">入门</a></li>
<li><a href="#中级篇">中级篇</a></li>
<li><a href="#高级篇">高级篇</a></li>
<li><a href="#工程化">工程化</a></li>
<li><a href="#兼容性">兼容性</a></li>
<li><a href="#前端特定">前端特定</a></li>
<li><a href="#软件工程">软件工程</a></li>
<li><a href="#调试">调试</a></li>
<li><a href="#测试">测试</a></li>
<li><a href="#性能与优化">性能与优化</a></li>
<li><a href="#设计">设计</a></li>
<li><a href="#seo">SEO</a></li>
</ul></li>
</ul></li>
<li><a href="#快速学习新的框架">快速学习新的框架</a><ul>
<li><a href="#快速学习是基本能力">快速学习是基本能力</a></li>
<li><a href="#如何学习新框架守-破-离">如何学习新框架：守-破-离</a><ul>
<li><a href="#守应用业务知识">守：应用业务知识</a></li>
<li><a href="#破学习框架核心">破：学习框架核心</a></li>
<li><a href="#离探索更多可能性">离：探索更多可能性</a></li>
</ul></li>
<li><a href="#小结">小结</a></li>
<li><a href="#选择合适的前端框架">选择合适的前端框架</a><ul>
<li><a href="#angular一站式提高生产力">Angular，一站式提高生产力</a></li>
<li><a href="#react组件化提高复用">React，组件化提高复用</a></li>
<li><a href="#vue.js简单也是提高效率">Vue.js，简单也是提高效率</a></li>
</ul></li>
</ul></li>
<li><a href="#构建系统资深分界线">构建系统：资深分界线</a><ul>
<li><a href="#为什么构建很重要">为什么构建很重要</a></li>
<li><a href="#构建工具">构建工具</a></li>
<li><a href="#构建流程">构建流程</a><ul>
<li><a href="#构建示例">构建示例</a></li>
<li><a href="#自动刷新">自动刷新</a></li>
<li><a href="#转译">转译</a></li>
<li><a href="#预处理">预处理</a></li>
</ul></li>
</ul></li>
<li><a href="#什么是前端的架构能力">什么是前端的架构能力</a><ul>
<li><a href="#标准的-spa-构架实践">“标准”的 SPA 构架实践</a><ul>
<li><a href="#前后端分离">前后端分离</a></li>
<li><a href="#无状态-api">无状态 API</a></li>
</ul></li>
<li><a href="#workflow">workflow</a><ul>
<li><a href="#前后端分离的工作方式">前后端分离的工作方式</a></li>
</ul></li>
<li><a href="#风格指南styleguide">风格指南：StyleGuide</a></li>
<li><a href="#演进">演进</a></li>
<li><a href="#最佳实践框架">最佳实践：框架</a><ul>
<li><a href="#jquery-tinymce">jQuery + TinyMCE</a></li>
<li><a href="#jquery-vue">jQuery + Vue</a></li>
</ul></li>
</ul></li>
<li><a href="#自动化提高效率">自动化提高效率</a><ul>
<li><a href="#自动化测试加快上线流程">自动化测试加快上线流程</a><ul>
<li><a href="#测试-1">测试</a></li>
<li><a href="#ui-测试">ui 测试</a></li>
<li><a href="#截屏测试">截屏测试，</a></li>
</ul></li>
<li><a href="#自动构建">自动构建</a></li>
<li><a href="#自动化部署">自动化部署</a><ul>
<li><a href="#持续集成">持续集成</a></li>
</ul></li>
</ul></li>
<li><a href="#前端应用的架构与设计模式">前端应用的架构与设计模式</a><ul>
<li><a href="#散弹式架构---jquery">散弹式架构 -&gt; jQuery</a></li>
<li><a href="#分层结构-mv">分层结构 MV*</a></li>
<li><a href="#处理数据-pipe-and-filter">处理数据 pipe and filter</a></li>
<li><a href="#数据显示-观察者模式">数据显示 观察者模式</a></li>
<li><a href="#数据通讯">数据通讯</a><ul>
<li><a href="#消息通讯">消息通讯</a></li>
<li><a href="#数据通讯shared-repository">数据通讯：shared repository</a></li>
<li><a href="#数据通讯local-storage">数据通讯：local storage</a></li>
</ul></li>
</ul></li>
<li><a href="#软技能篇">软技能篇</a></li>
<li><a href="#在做业务的过程中提升技术">在做业务的过程中提升技术</a><ul>
<li><a href="#测试-2">测试</a></li>
<li><a href="#代码可读性">代码可读性</a></li>
<li><a href="#有意图的提升">有意图的提升</a></li>
</ul></li>
<li><a href="#持续学习走出下一个jquery">持续学习：走出下一个『jQuery』</a><ul>
<li><a href="#jquery-已经落后了下一个-jquery-已经出现了">jQuery 已经落后了？下一个 jQuery 已经出现了</a></li>
<li><a href="#持续学习">持续学习</a></li>
<li><a href="#掌握思想">掌握思想</a></li>
<li><a href="#后端技能">后端技能</a></li>
</ul></li>
<li><a href="#软技能">软技能</a><ul>
<li><a href="#知识管理">知识管理</a></li>
<li><a href="#debug-发现问题">Debug: 发现问题</a></li>
</ul></li>
<li><a href="#扩展篇">扩展篇</a></li>
<li><a href="#前端知识体系的广度与深度">前端知识体系的广度与深度</a><ul>
<li><a href="#前端与后台的对比">前端与后台的对比</a></li>
<li><a href="#用户体验设计">用户体验设计</a></li>
<li><a href="#前端的广度">前端的广度</a></li>
</ul></li>
<li><a href="#前端的趋势">前端的趋势</a><ul>
<li><a href="#微服务与微前端">微服务与微前端</a></li>
<li><a href="#bff">BFF</a></li>
<li><a href="#状态管理">状态管理</a></li>
<li><a href="#跨平台">跨平台</a></li>
<li><a href="#ui-生成">UI 生成</a></li>
</ul></li>
<li><a href="#转型前端指南">转型前端指南</a><ul>
<li><a href="#改变">改变</a></li>
<li><a href="#后台转前端的挑战">后台转前端的挑战</a></li>
<li><a href="#其他编程领域转前端">其他编程领域转前端</a></li>
<li><a href="#其他行业转前端">其他行业转前端</a><ul>
<li><a href="#劝退">劝退</a></li>
<li><a href="#立意已决">立意已决</a></li>
</ul></li>
</ul></li>
<li><a href="#前端跨行指南">前端跨行指南</a><ul>
<li><a href="#移动开发混合开发">移动开发：混合开发</a></li>
<li><a href="#桌面应用">桌面应用</a></li>
<li><a href="#vr">VR</a></li>
<li><a href="#硬件">硬件</a></li>
<li><a href="#其它">其它？</a></li>
</ul></li>
</ul>
</nav>
<h1 id="前端进阶指南">前端进阶指南</h1>
<h2 id="什么是前端">什么是前端</h2>
<p>作为一本前端进阶的书，没有理由去强调一下<strong>什么是前端</strong>？可是，当你说前端的时候，我也说前端的时候，我们说的是同一个前端吗？</p>
<p>我理解下的前端，指广泛意义上的前端。又可以称为『客户端』，泛指：与用户做交互的应用。如桌面浏览器上的浏览器、图形用户界面，移动设备上的应用程序、浏览器，又或者是各种智能、联网设备的交互都可以归属于前端。</p>
<p>因而，在这种意义上来说，前端要做的不仅仅是 Web，还可以是混合应用，原生应用等等。</p>
<p>这就意味着：</p>
<ul>
<li>你可以使用 CSS Layout + React Native 编写移动程序</li>
<li>你可以使用 Electron 来编写桌面应用</li>
<li>你可以使用 React VR 来编写 VR 应用</li>
<li>等等</li>
</ul>
<p>这种时候，前端指的是，我们使用 <strong>样式（类CSS） + 类JavaScript + 模板（HTML、XML等</strong> 编写的应用。</p>
<p>如果那些用 JavaScript 编写的应用，也划分到前端的范畴，那么：</p>
<ul>
<li>你还可以使用 JavaScript 与 Ruff、 Tessel 对硬件进行编程</li>
<li>你还可以使用 Node.js 来编写后台应用，又或者是 BFF （backend for frontend）层</li>
</ul>
<p>在这里，我们将前端定义为 类CSS + 类 JavaScript + 模板。因为没有图形应用的应用，难以直观的与用户进行交互，做不了『客户端』应用。在这一定义下，这一类型的应用有，桌面应用、桌面网页、移动网页、移动应用等等，现在发展的有 VR 技术等等。</p>
<h2 id="本书内容">本书内容</h2>
<h1 id="硬技能篇">硬技能篇</h1>
<h1 id="前端知识要点">前端知识要点</h1>
<p>罗列一下，一些必要的知识点</p>
<p>希望读者都是知道的，以便于</p>
<p>作为一个领域，它拥有相当多的知识点。</p>
<p>如果读者已经知道了这些，那么可以跳过这一章的内容。</p>
<h2 id="前端应用的生命周期">前端应用的生命周期</h2>
<figure>
<img src="images/refe.png" alt="前端应用的生命周期" /><figcaption>前端应用的生命周期</figcaption>
</figure>
<h3 id="入门">入门</h3>
<p>在我理解下的基础知识，就是我们可以写一些基本的样式，并能对页面的元素进行操作。举例来说，就是我们用Spring和JSP写了一个博客，然后我们可以用jQuery来对页面进行一些简单的操作，并可以调用一些API。因此，我们需要基本的HTML / CSS知识。只是要写好CSS并不是一件简单的事，这需要很多实战经验。随后，我们还需要有JavaScript的经验，要不怎么做前端呢？</p>
<p>同时，我们还需要对DOM有一些基础的了解，才能做一些基本的操作，如修改颜色等等。在这种情况下，最简单的方案就是使用jQuery这样的工具。不过，如果可以自己操作DOM是再好不过的了。</p>
<h3 id="中级篇">中级篇</h3>
<p>中级篇就更有意思了，现在我们就需要对页面进行更复杂的操作。Ajax和JSON这两个技能是必须的，当我们要动态的改变页面的元素时，我们就需要从远程获取最新的数据结果。并且我们也需要提交表单到服务器，RESTful就是必须要学会的技能。未来我们还需要Fetch API，ReactiveX这些技能。</p>
<p>除此我们还需要掌握好HTML的语义化，像DIV / CSS这也会必须会的技能，我们应该还会使用模板引擎和SCSS / SASS。而这个层面来说，我们开始使用Node.js来完成前端的构建等等的一系列动作，这时候必须学会使用命令行这类工具。并且，在这时候我们已经开始构建单页面应用了。</p>
<h3 id="高级篇">高级篇</h3>
<p>JavaScript是一门易上手的语言，也充满了相当多的糟粕的用法。几年前人们使用CoffeeScript编成成JavaScript来编写更好的前端代码，现在人们有了ES6、TypeScript和WebPack来做这些事。尽管现在浏览器支持不完善，但是他们是未来。同样的还有某些CSS3的特性，其对于某些浏览器来说也是不支持的。而这些都是基于语言本来说的，要写好代码，我们还需要掌握面向对象编程、函数式编程、MVC / MVVM / MV*这些概念。作为一合格的工程师，我们还需要把握好安全性（如跨域），做好 授权（如HTTP Basic、JWT等等）。</p>
<h3 id="工程化">工程化</h3>
<p>这个标题好像是放错了，这部分的内容主要都是自动构建的内容。首先，我们需要有基本的构建工具，无论你是使用gulp、grunt，还是只使用npm，这都不重要。重要的是，你可以自动化的完成构建的工具，编译、静态代码分析（JSLint、CSS Lint、TSLint）、对代码质量进行分析（如Code Climate，可以帮你检测出代码中的Bad Smell）、运行代码中的测试，并生成测试覆盖率的报告等等。这一切都需要你有一个自动构建的工作流。</p>
<h3 id="兼容性">兼容性</h3>
<p>虽然我们离兼容IE6的时代已越来越远了，但是我们仍然有相当多的兼容性工作要做。基本的兼容性测试就是跨浏览器的测试，即Chrome，IE，Firefox，Safari等等。除此还有在不同的操作系统上对同一浏览器的测试，某些情况下可能表现不一致。如不同操作系统的字体大小，可能会导致一些细微的问题。而随着移动设备的流行，我们还需要考虑下不同Android版本下的浏览器内核的表现不致，有时候还要一下不成器的Windows Phone。除此，还有同一个浏览器的不同版本问题，常见于IE。。</p>
<h3 id="前端特定">前端特定</h3>
<p>除了正常的编码之外，前端还有一些比较有意思的东西，如CSS3和JavaScript动画。使用Web字体，可惜这个不太适合汉字使用。还有Icon字体，毕竟这种字体是矢量的。不过Icon字体还有一些问题，如浏览器对其的抗锯齿优化，还有一个痛是你得准备四种不同类型的字体文件。因此，产生了一种东西SVG Sprite，在以前这就是CSS Sprite，只是CSS Sprite不能缩放。最后，我们还需要掌握一些基本的图形和图表框架的使用。</p>
<h3 id="软件工程">软件工程</h3>
<p>这一点上和大部分语言的项目一样，我们需要使用版本管理软件，如git、svn，又或者是一些内部的工具。总之你肯定要有一个，而不是 2016.07.31.zip这种文件。然后，你还需要一些依赖管理工具，对于那些使用Webpack、Browserify来将代码编写成前端代码的项目来说，npm还是挺好用的。不过就个人来说，对于传统的项目来说我总觉得bower有些难用。我们还需要模块化我们的源码文件，才能使其他人更容易开始项目。</p>
<h3 id="调试">调试</h3>
<p>作为一个工程师来说，调试是必备的技能。大部分浏览器都自带有调试工具，他们都不错——如果你使用过的话。在调试的过程中，直接用Console就可以输出值、计算值等等。如果你的项目在构建的过程中有一些问题，你就需要debugger这一行代码了。在一些调用远程API的项目里，我们还需要一些更复杂的工具，即抓包工具。在调试移动设备时，像Wireshark、Charles这一类的工具，就可以让我们看到是否有一些异常的请求。当然在这个时候，还有一个不错的工具就是像Chrome自带的远程设备调试。对于移动网站来说，还要有Responsive视图。</p>
<h3 id="测试">测试</h3>
<p>我遇到的很多前端工程师都是不写测试的，于是我便把它单独地抽了出现。对于一个前端项目来说，正常情况下，我们要有单元测试、功能测试，还有要一些UI测试来验证页面间是否可以跳转。对于依赖于第三方服务的应用来说，还要有一个Mock的服务来方便我们测试。如果是前后端分离的项目，我们还需要有集成测试。</p>
<h3 id="性能与优化">性能与优化</h3>
<p>要对Web应用进行性能优化，可能不是一件容易的事，有时候我们还知道哪些地方可以优化。这时候人们就可以使用Yahoo的YSlow，或者我最喜欢的Google PageSpeed来检测页面的一些问题，如有没有开启GZip、有没有压缩、合并、Minify JS代码等等。我们还应该借助于NetWork这一类的工具，查看页面加载时，一些比较漫的资源文件，并对其进行优化。在一些情况下，我们还需要借助如Chrome的Timline、Profiel等工具来查看可以优化的地方。</p>
<h3 id="设计">设计</h3>
<p>前端工程师还需要具备基本的UI技能。多数情况下拿到的只是一张图，如果是一个完整的页面，我们就需要快速分割页面布局。而依赖于不同的页面布局，如响应式、网格、FlexBox布局也会有不同的设计。而有些时候，我们就需要自己规划，制作一个基本的线框图（Wireframe）等等。</p>
<h3 id="seo">SEO</h3>
<p>如果以搜索引擎作为流量来源，我们还需要考虑页面的内容，除非你用的是竞争排名。像Sitemap可能就不是我们考虑的内容，而我们还要考虑很多点。首先，我们需要保证页面的内容是对于搜索引擎是可见的，并且对应的页面还要有基本的Title、Description和Keyword。然后在一些关键的字体，如栏目标题等等可以用H2之类的大字的地方就不要放过。同时在页面设计的过程中，我们还需要考虑一些内部链接的建设。它即可以提供页面的可见度，又可以提高排名。最后，如果你是面向的是Google等支持结构化数据的搜索引擎，你还需要考虑一下MicroData / MicroFormat这一类东西。</p>
<h1 id="快速学习新的框架">快速学习新的框架</h1>
<p>今天很流行的 Web 框架，半年以后，可能就会在市场上被『淘汰』——技术选型的时候，不被开发人员推荐；又或者它已经推出了全新的版本，使用了全新的 API，我们便需要更新现有应用。</p>
<p>前端框架丰富多彩的今天，快速学习新的框架是<strong>每个前端程序员的必备技能</strong>。</p>
<h2 id="快速学习是基本能力">快速学习是基本能力</h2>
<p>后端程序员，开始一个新的 Web 项目时：</p>
<ul>
<li>使用 Java 语言，八成会选用 Spring 框架。</li>
<li>使用 Ruby 语言，八成会选用 Rails 框架。</li>
<li>使用 Scala 语言，八成会先用 Play 框架。</li>
</ul>
<p>而只使用 JavaScript 的前端程序员，开始一个前端项目时。你有几成的把握，能判断他/她出会使用哪个框架？</p>
<p>后端程序员在有限的时间内，只会使用固定的技术栈，固定的框架。对于大部分的公司来说，使用相同的后台语言，是一个更好的选择——即可以减少带成本，又可以沉淀下技术积累。</p>
<p>而前端则不一样，不同的项目都有各自的需求，因此采用使用不同的技术栈。简单的，可以直接使用原生的 JavaScript 完成，又或者是使用 jQuery 完成开发。稍微复杂一点的项目，采用容易上手的 Vue.js 是一个不错的选择。更复杂的项目，便可以使用 Angular，可以方便后台程序员转到前端。</p>
<p>因此，工作一定年限的程序员，都使用过不同的框架。可是，不同的程序员上手新框架的速度，总会存在一定的差异。</p>
<p>那么，怎样才能快速上手一个新的框架呢？</p>
<p>学习新的前端框架，要么该框架很火——即<strong>热闹驱动开发</strong>（Hype Driven Development，HDD），要么你们将采用该框架。在采用新框架的动机里，有一种是：技术演进。使用新的技术、框架，来替换现有的框架。旧的框架在某些地方上，存在着明显的缺陷。</p>
<p>这种情形下，业务知识本身是不变的，只是要由框架本身来应对业务的变化。因此，使用新的技术来替换旧有的框架，就相当的容易——重写，我们甚至可以直接复制、粘贴，大量原有的代码。只是，仅仅做到重写业务逻辑是不够的。我们还要掌握新的框架的核心，并探索更多的可能性。</p>
<h2 id="如何学习新框架守-破-离">如何学习新框架：守-破-离</h2>
<p>我在学校的时候，看到一个关于编程语言的学习建议：<strong>学习三种以上的编程语言，并且它们最好是三种不同类型的语言</strong>。如面向过程的编程语言 C 、脚本语言 JavaScript、Python，面向对象的编程语言 Java、再加上个近年来火热的函数式编程语言，到底也就差不多了。当我们学习了一门语言，再上手一门相似风格的语言，也是相当轻松地一件事。当我们学习了不同类型的几种语言，未来就可以轻松地绝大多数的语言。</p>
<p>相似的，学习使用 Web 框架也是如此的。现在，对于我而来，使用一个『新框架的姿势』是：</p>
<ul>
<li>买本中文书或者找个教程、官方的 Guide，花个十几分钟了解一下框架的『知识图谱』。</li>
<li>直接找个官方的示例，运行一下 Demo。</li>
<li>上手写写应用。</li>
<li>查看官方文档，看看自己是不是漏掉了什么重要的东西。</li>
</ul>
<p>它与我在公司接受培训的时候，学习到的『守破离』观点相似。在保留原来业务的情况下，一步步向前演进。</p>
<h3 id="守应用业务知识">守：应用业务知识</h3>
<p>在现有的业务上，使用新的框架是一件容易的事。拿上一份框架的说明书、一份需求文档、一个搜索引擎，就可以很容易地复制出一个产品。唯一的门槛是，你需要会读懂这些内容。这有点像新的知识阶级，只是门槛不再是识字与否，而在于是否能懂编程的知识。</p>
<p>正如维基百科上，对于『守』的介绍一样：</p>
<blockquote>
<p>最初阶段须遵从老师教诲，认真练习基础，达到熟练的境界。</p>
</blockquote>
<p>新手期的我们，拿到一个新的框架，要一下子对它了运用自如，是一件很难的事。我们只能在一个又一个的练习中，尝试去掌握框架的知识。如，原先我们使用的是 Backbone + jQuery 完成的前端应用，现在要切换到 Vue.js。我们要做的便是尝试使用 Vue.js，并不断地练习一些相关的用法。而在熟练之后，我们也会练习我们的基本套路，如在上文中说到的『新框架的姿势』。</p>
<p>而如果不考虑练习本身的时间因素，便只剩下的一个问题是：<strong>如何找到一个合适的练习项目</strong>。然而，这样的项目在 GitHub 上有很多。可是即使它能满足我们的需求，我们有时候也不知道怎么练习？</p>
<p>我想问题的关键在于：我们手上没有一个已经成型的业务系统。因此，我建议大家可以从创建一个博客开始做起，先使用现有的技术，再使用新的技术，慢慢的一点点往上添加内容。如我的博客，最早是基于 Django + Bootstrap，慢慢的我添加了一些新的东西：</p>
<ul>
<li>用于为搜索提供建议的 AutoSuggest</li>
<li>移动应用 API 及博客搜索 API</li>
<li>微信搜索支持功能</li>
<li>支持 Google AMP 来快速加载页面</li>
<li>Google Micro Data</li>
</ul>
<p>尽管越来越多的功能，有一些已经不再维护、关闭了。可是，它让我有机会去练习一些新的技术，掌握一些技术背后的思想，得到一些框架相关的结论。而不是每次与别人讨论时，说：xx 说 xx 框架有这样的问题，而是我试过这个框架，它有这样的问题。</p>
<h3 id="破学习框架核心">破：学习框架核心</h3>
<blockquote>
<p>基础熟练后，试着突破原有规范让自己得到更高层次的进化。</p>
</blockquote>
<p>转换技术栈，本身没有什么技术含量，但是能帮助稳固知识。当我们已经熟悉使用这个框架完成业务时，便可以细入相关思想。</p>
<p>了解这个框架的能力，生成一份与框架有关的索引，也可以用脑图的形势来整理这些内容。</p>
<p>如：</p>
<figure>
<img src="images/eks-example.jpg" alt="嵌入式系统工程师图谱" /><figcaption>嵌入式系统工程师图谱</figcaption>
</figure>
<p>举例，如 Angular + TypeScript，还有其他更多的可能性</p>
<p>同时，我们还应该理解框架背后的原理。不一定深入，但是觉得去探究。如：</p>
<ul>
<li>MV* 思想</li>
<li>双向数据绑定的基本原理</li>
</ul>
<p>这些都在我的知乎专栏上《我的职业是前端工程师》有深入的介绍，有时候的读者建议多阅读相关的内容。</p>
<h3 id="离探索更多可能性">离：探索更多可能性</h3>
<blockquote>
<p>在更高层次得到新的认识并总结，自创新招数另辟出新境界。</p>
</blockquote>
<p>在那之上，创造出一些新的框架。</p>
<p>如 Redux，最早是运行的 React.js 之上。Angular 2 出来了后，有了 xx。小程序出来后，有了 xx。</p>
<p>同理于此，当出现微信小程序的一两个星期内，我写了几篇原理相关的文章，并介绍了如何创建一个属于自己的小程序应用框架 WINV。又或者是我在对 Virtual Dom 有一定的了解后，便深入 Virtual Dom 的代码，写了一个基于 Virtual Dom 的测试辅助框架 <a href="http://github.com/phodal/luffa">Luffa</a>。</p>
<p>而这些，只有我们理解他们的原理之后，我们才可能做到这样的事。</p>
<h2 id="小结">小结</h2>
<p>寻找心流</p>
<p>这些方法适用于大部分的人，但是不一定适合你。你只需要寻找到适合你的路，然后学习。</p>
<h2 id="选择合适的前端框架">选择合适的前端框架</h2>
<p>在《全栈应用开发：精益实践》一书中，我曾提到过影响技术选型的几个因素：</p>
<figure>
<img src="images/tech-decide.png" alt="选型因素" /><figcaption>选型因素</figcaption>
</figure>
<p><strong>锤子定律：寻找更大视野</strong></p>
<p><strong>年轻的时候，学会了 A 框架，总觉得 Z 网站用 A 框架来实现会更好</strong>，一定不会像今天这样经常崩溃、出Bug。**时间一长，有时候就会发现，Z 网站使用 A 不合适，他们的问题并不是框架的问题，而是运维的问题。</p>
<p>在《咨询的奥秘》一书中，提到一个有意思的定律“锤子定律”（又称为工具定律）——<strong>圣诞节收到一把锤子的孩子，会发现所有东西都需要敲打</strong>。 出现这种情况的主要原因是，<strong>开发者对一个熟悉的工具过度的依赖</strong>。</p>
<p>认真观察，就会发现这个现象随处可见。当一个新手程序员学会了某个最新的框架，通常来说这个框架有着更多的优点，这个时候最容易出现的想法是：<strong>替换现有的框架</strong>。可是，现有的框架并没有什么大的问题。并且凭估不充分时，新的框架则存在更多的风险。</p>
<p>并且，对于某个熟悉工具的过度依赖，特别容易影响到技术决策——看不到更多的可能性。这时候，我们就需要头脑风暴。但是这种情况下，头脑风暴很难帮助解决问题。在这个时候，拥有更多项目、框架经验的人，可能会做出更好的选择。</p>
<h3 id="angular一站式提高生产力">Angular，一站式提高生产力</h3>
<p>与 Backbone 同一时代诞生的 Angular 便是一个大而全的 MVC 框架。在这个框架里，它提供了我们所需要的各种功能，如模块管理、双向绑定等等。它涵盖了开发中的各个层面，并且层与层之间都经过了精心调适。</p>
<p>我们所需要做的便是遵循其设计思想，来一步步完善我们的应用。Angular.js 的创建理念是：即声明式编程应该用于构建用户界面以及编写软件构件，而命令式编程非常适合来表示业务逻辑。</p>
<p>我开始使用 Angular.js 的原因是，我使用 Ionic 来创建混合应用。出于对制作移动应用的好奇，我创建了一个又一个的移动应用，也在这时学会了 Angular.js。对于我而言，选择合适的技术栈，远远比选择流行的技术栈要重要得多，这也是我喜欢使用 Ionic 的原因。当我们在制作一个应用，它对性能要求不是很高的时候，那么我们应该选择开发速度更快的技术栈。</p>
<p>对于复杂的前端应用来说，基于 Angular.js 应用的运行效率，仍然有大量地改进空间。在应用运行的过程中，需要不断地操作 DOM，会造成明显的卡顿。对于 WebView 性能较差或早期的移动设备来说，这就是一个致命伤。</p>
<p>幸运的是在 2016 年底，Angular 团队推出了 Angular 2，它使用 Zone.js 实现变化的自动检测、</p>
<p>而迟来的 Angular 2 则受<strong>奥斯本效应</strong><a href="#fn1" class="footnoteRef" id="fnref1"><sup>1</sup></a>的影响，逼得相当多的开发者们开始转向其它的框架。</p>
<h3 id="react组件化提高复用">React，组件化提高复用</h3>
<p>从 Backbone 和 Angular.js 的性能问题上来看，我们会发现 DOM 是单页面应用急需改善的问题——主要是DOM 的操作非常慢。而在单页面应用中，我们又需要处理大量的 DOM，性能就更是问题了。于是，采用 Virtual DOM 的 React 的诞生，让那些饱受性能苦恼的开发者欢迎。</p>
<p>传统的 DOM 操作是直接在 DOM 上操作的，当需要修改一系列元素中的值时，就会直接对 DOM 进行操作。而采用 Virtual DOM 则会对需要修改的 DOM 进行比较（DIFF），从而只选择需要修改的部分。也因此对于不需要大量修改 DOM 的应用来说，采用 Virtual DOM 并不会有优势。开发者就可以创建出可交互的 UI。</p>
<p>除了编写应用时，不需要对 DOM 进行直接操作，提高了应用的性能。React 还有一个重要思想是组件化，即 UI 中的每个组件都是独立封装的。与此同时，由于这些组件独立于 HTML，使它们不仅仅可以运行在浏览器里，还能作为原生应用的组件来运行。</p>
<p>同时，在 React 中还引入了 JSX 模板，即在 JS 中编写模板，还需要使用 ES 6。令人遗憾的是 React 只是一个 View 层，它是为了优化 DOM 的操作而诞生的。为了完成一个完整的应用，我们还需要路由库、执行单向流库、web API 调用库、测试库、依赖管理库等等，这简直是一场噩梦。因此为了完整搭建出一个完整的 React 项目，我们还需要做大量的额外工作。</p>
<p>大量的人选择 React 还有一个原因是：React Native、React VR 等等，可以让 React 运行在不同的平台之上。我们还能通过 React 轻松编写出原生应用，还有 VR 应用。</p>
<p>在看到 Angular 2 升级以及 React 复杂性的时候，我相信有相当多的开发者转而选择 Vue.js。</p>
<h3 id="vue.js简单也是提高效率">Vue.js，简单也是提高效率</h3>
<p>引自官网的介绍，Vue.js 是一套构建用户界面的渐进式框架，专注于MVVM 模型的 ViewModel 层。Vue.js 不仅简单、容易上手、配置设施齐全，同时拥有中文文档。</p>
<p>对于使用 Vue.js 的开发者来说，我们仍然可以使用 熟悉的 HTML 和 CSS 来编写代码。并且，Vue.js 也使用了 Virtual DOM、Reactive 及组件化的思想，可以让我们集中精力于编写应用，而不是应用的性能。</p>
<p>对于没有 Angular 和 React 经验的团队，并且规模不大的前端项目来说，Vue.js 是一个非常好的选择。</p>
<p>虽然 Vue.js 的生态与 React 相比虽然差上一截，但是配套设施还是相当齐全的，如 Vuex 、 VueRouter。只是，这些组件配套都由官方来提供、维护，甚至连 awesome-vue 也都是官方项目，总觉得有些奇怪。</p>
<p>除此，Vue.js 中定义了相当多的规矩，这种风格似乎由 jQuery 时代遗留下来的。照着这些规矩来写代码，让人觉得有些不自在。</p>
<p>和 React 相似的是，Vue.js 也有相应的 Native 方案 Weex，仍然值得我们期待。</p>
<h1 id="构建系统资深分界线">构建系统：资深分界线</h1>
<p>Yeoman 生成脚手架，并且现在的主流前端框架都提供了相似的工</p>
<p>打包 -&gt; 压缩 -&gt; 上传 -&gt; 解压 -&gt; 替换 -&gt; 重启</p>
<p>重点在于：提高工作效率</p>
<h2 id="为什么构建很重要">为什么构建很重要</h2>
<p>过去我们打开编辑器、浏览器、修改代码、刷新页面，如下图所示：</p>
<figure>
<img src="images/basic-workflow.png" alt="前端应用的开发流程" /><figcaption>前端应用的开发流程</figcaption>
</figure>
<p>这个过程仍然没有发生太大的变化，只是很多的步骤都被自动化了：</p>
<p>我们只需要修改代码，诸如 watchman 这样的工具就检测到修改，而 Browsersync 则可以帮助我们自动刷新页面。</p>
<h2 id="构建工具">构建工具</h2>
<p>取决于你所使用的技术栈</p>
<p>SASS、SCSS 因不同的情况而异</p>
<p>webpack</p>
<p>npm</p>
<p>grunt / gulp</p>
<h2 id="构建流程">构建流程</h2>
<figure>
<img src="images/build-workflow.png" alt="前端构建流程" /><figcaption>前端构建流程</figcaption>
</figure>
<p>LiveReload</p>
<p>Bower</p>
<p>concat -&gt; init -&gt; lint -&gt; min -&gt; qunit -&gt; server -&gt; test -&gt; watch</p>
<h3 id="构建示例">构建示例</h3>
<p>如下是混合应用框架 Ionic 执行 <code>ionic serve</code> 时的启动日志：</p>
<pre><code>[11:43:58]  ionic-app-scripts 1.3.4
[11:43:58]  watch started ...
[11:43:58]  build dev started ...
[11:43:58]  clean started ...
[11:43:58]  clean finished in 1 ms
[11:43:58]  copy started ...
[11:43:58]  transpile started ...
[11:44:03]  transpile finished in 5.17 s
[11:44:03]  preprocess started ...
[11:44:03]  deeplinks started ...
[11:44:03]  deeplinks finished in 132 ms
[11:44:03]  preprocess finished in 132 ms
[11:44:03]  webpack started ...
[11:44:03]  copy finished in 5.49 s
[11:44:26]  webpack finished in 22.94 s
[11:44:26]  sass started ...
[11:44:29]  sass finished in 3.21 s
[11:44:29]  postprocess started ...
[11:44:29]  postprocess finished in 85 ms
[11:44:29]  lint started ...
[11:44:29]  build dev finished in 31.57 s
[11:44:29]  watch ready in 31.69 s</code></pre>
<p>这个过程中，它会完成如下的步骤：</p>
<p>watch -&gt; build dev -&gt; clean -&gt; copy -&gt; transpile -&gt; preprocess (deeplinks) -&gt; webpack (copy) -&gt; sass -&gt; postprocess -&gt; build dev</p>
<h3 id="自动刷新">自动刷新</h3>
<h3 id="转译">转译</h3>
<h3 id="预处理">预处理</h3>
<h1 id="什么是前端的架构能力">什么是前端的架构能力</h1>
<blockquote>
<p>远离最佳实践，除非你能接受其带来的成本</p>
</blockquote>
<p>当我们谈及『前端的架构』时，我们讨论的是复杂前端应用的架构——如果只是一个 jQuery + Bootstrap 完成的应用，那么它的架构想必是『散弹式』的应用，没有复杂的逻辑可言。</p>
<h2 id="标准的-spa-构架实践">“标准”的 SPA 构架实践</h2>
<p>复杂的前端应用，多数是 SPA（单页面应用），这就意味着系统的架构是前后端分离的。可前后端分离并意味着，</p>
<h3 id="前后端分离">前后端分离</h3>
<h3 id="无状态-api">无状态 API</h3>
<h2 id="workflow">workflow</h2>
<h3 id="前后端分离的工作方式">前后端分离的工作方式</h3>
<p>实现上，它主要关注点是：API 的设计。API 设计应该由前端开发者来驱动的。后台只提供前端想要的数据，而不是反过来的。后台提供数据，前端从中选择需要的内容。</p>
<ul>
<li>使用文档规范 API</li>
<li>契约测试：基于持续集成与自动化测试</li>
<li>前端测试与 API 适配器</li>
</ul>
<h2 id="风格指南styleguide">风格指南：StyleGuide</h2>
<p>与之前的构建系统相比，StyleGuide 便是一种无法用工具强制执行的规范。尽管可以采用工具来做类似的事情，但是并非应该强制去做。</p>
<ul>
<li>代码规范</li>
<li>函数限制。Java -&gt; 30 行</li>
</ul>
<h2 id="演进">演进</h2>
<p>当前技术栈，未来技术栈，切换。</p>
<p>使用了 Backbone，性能上出现一些瓶颈。</p>
<p>是不是要重写服务。</p>
<p>后台不能满足一些需求，考虑使用 BFF 吗</p>
<p>选用合适的策略，并保证没有问题。</p>
<h2 id="最佳实践框架">最佳实践：框架</h2>
<p>在这个领域，并不存在最佳的实践。首先的问题是，要找出我们真正想实现的功能，在这之后再去完成下一个步骤。而不是先找行业中最好的实践，再将这些实践应用</p>
<p>jQuery 在简单的前端页面里，仍然是最好的选择。</p>
<h3 id="jquery-tinymce">jQuery + TinyMCE</h3>
<h3 id="jquery-vue">jQuery + Vue</h3>
<p>不久前，我需要一个 UI 框架及前端框架来实现简单的逻辑功能，并且它还应该相当的小。因此，我首先排队了 jQuery + Bootstrap，它们在体积上不太符合我的要求。</p>
<ul>
<li>发出一个 Ajax 请求，验证 Token</li>
<li>如果返回的 Token 是有效的，则生成</li>
</ul>
<p>提炼出核心技术，</p>
<p>对于大的公司来讲，都会要求拥有自己的核心技术。</p>
<p>在网上，各式各样的前端开发最佳实践层出不穷，</p>
<p>最意味着，在某些方面已经是到了极致。</p>
<h1 id="自动化提高效率">自动化提高效率</h1>
<h2 id="自动化测试加快上线流程">自动化测试加快上线流程</h2>
<h3 id="测试-1">测试</h3>
<p>测试页面的输出结果，保证元素的准确性~</p>
<p>stub: 结果，返回预期的结果。</p>
<p>mock: 行为，预期方法被调用。</p>
<h3 id="ui-测试">ui 测试</h3>
<p>React Test Renderer</p>
<pre><code>&lt;Modal
  animationType=&quot;fade&quot;
  hardwareAccelerated={false}
  onRequestClose={[Function]}
  transparent={true}
  visible={false}
&gt;
  &lt;View&gt;
    &lt;View
      style={
        Object {
          &quot;alignItems&quot;: &quot;center&quot;,
          &quot;backgroundColor&quot;: &quot;rgba(0,0,0,.1)&quot;,
          &quot;height&quot;: 1334,
          &quot;justifyContent&quot;: &quot;center&quot;,
        }
      }
    &gt;
  ...    </code></pre>
<h3 id="截屏测试">截屏测试，</h3>
<p>对于那些 UI 改动较小的系统来说，这</p>
<p>而我们知道页面截图尽管可以作为版本管理的一部分，但是一个不可比对的结果</p>
<p>而诸如，react-test-render， Virtual Dom 测试</p>
<p>那么，对于普通的 HTML 结构的</p>
<figure>
<img src="images/PhantomCSS.png" alt="PhantomCSS" /><figcaption>PhantomCSS</figcaption>
</figure>
<h2 id="自动构建">自动构建</h2>
<p>在之前的构建系统一节里，我们讲了 xx。剩下要做的就是生成打包好的源码</p>
<p>Gulp、Grunt</p>
<h2 id="自动化部署">自动化部署</h2>
<p>只需要一些 持续集成 的基础，如 Jenkins</p>
<h3 id="持续集成">持续集成</h3>
<h1 id="前端应用的架构与设计模式">前端应用的架构与设计模式</h1>
<h2 id="散弹式架构---jquery">散弹式架构 -&gt; jQuery</h2>
<p>项目达到一定的程度，jQuery 便有些难以管理，我们不知道哪个地方还操作了 DOM。修改了 A 处的 selector，可能会影响 B 处的 selector。</p>
<p>这样的修改方式称为『散弹式架构』，它来自于 散弹式修改（shotgun surgery，出处《重构：改善既有代码的设计》），</p>
<p>在使用 Backbone 的过程中，如果你采用了继承 View 的方式，你也会遇到这种遇到问题。</p>
<h2 id="分层结构-mv">分层结构 MV*</h2>
<p>典型的 SPA 应该会具有的模式，如 Angular，Vue.js</p>
<h2 id="处理数据-pipe-and-filter">处理数据 pipe and filter</h2>
<p>fetch、ajax、RxJS 从 API 处获取到数据</p>
<p>这个时候的数据首先会被转换为 JSON，再过滤到需要的字段，再对字段进行特殊的处理，如 HtmlEncoded，最后再 Render 到元素上。</p>
<p>当我们从服务器</p>
<h2 id="数据显示-观察者模式">数据显示 观察者模式</h2>
<p>双向绑定，即观察者模式，又可以称为发布订阅模式（Publish/Subscribe）</p>
<h2 id="数据通讯">数据通讯</h2>
<p>除了常规的数据获取，还有在不同的框架间传输数据，如 React Native 和 WebView 的 postMessage，Cordova 的 WebView 与原生插件间</p>
<h3 id="消息通讯">消息通讯</h3>
<h3 id="数据通讯shared-repository">数据通讯：shared repository</h3>
<p>其他消息通讯</p>
<h3 id="数据通讯local-storage">数据通讯：local storage</h3>
<p>??? black board</p>
<h1 id="软技能篇">软技能篇</h1>
<h1 id="在做业务的过程中提升技术">在做业务的过程中提升技术</h1>
<blockquote>
<p>“三个月经验，重复了五年”</p>
</blockquote>
<h2 id="测试-2">测试</h2>
<h2 id="代码可读性">代码可读性</h2>
<blockquote>
<p>与性能相比，可读性更加重要——绝大多数的软件，并不是写完就结束周期了。当然，倒掉的创业公司的软件除外。</p>
</blockquote>
<h2 id="有意图的提升">有意图的提升</h2>
<p>在一家大的公司里，不同的人总会有不同的运气：</p>
<p>运气好的人遇上一个好的项目，升职加薪，从此就走上了人生的巅峰。 运气差的人摊上一个差的项目，升不了职，少加了薪，并且还获得不了技术成长。 我刚毕业那会儿，所在团队的主要工作是，维护一个『又老又旧』的系统。比起写业务代码更不幸的是，我们的主要工作是修 Bug，bug，buG, bUg。</p>
<p>那一年多里，尽管都是维护旧系统和少量的新需求，我们还是在飞速的成长~~。而来源主要是：</p>
<ul>
<li>组内技术活动</li>
<li>花时间投入练习</li>
<li>假想项目的重构</li>
</ul>
<p>当你在有限的条件下，还能做出一定的成绩，到底还是相当有成就感的。</p>
<p>如果你觉得你的项目技术栈老旧，那么你一定在脑子里使用了 N 种技术栈，对他们进行重构了。并且当你有一些时间可以分配到上面，如下班前的一个小时时间，又或者黑客马拉松等等。那么，你一定会开始去做这样的事。</p>
<p>与上面的技术活动相比，这是一个对于业务（我的意思是，对于公司来说）更有价值，并且更容易说服别人的方式。</p>
<ul>
<li>学习别的项目的技术栈，然后将之应用到现有的系统上。</li>
<li>使用一个新的技术栈练习， 以此作为技术支撑，在未来替换现有的系统。</li>
</ul>
<h1 id="持续学习走出下一个jquery">持续学习：走出下一个『jQuery』</h1>
<p>不，仍然没有，</p>
<p>jQuery 的最大问题在于，简单如果上手，如 Vue 有可能便会流行，然后成为下一个 jQuery</p>
<h2 id="jquery-已经落后了下一个-jquery-已经出现了">jQuery 已经落后了？下一个 jQuery 已经出现了</h2>
<p>预测未来，不，我不可能。</p>
<p>对于，大公司或者内部系统的开发者来说，由于框架能满足应用的开发，因此很容易长期采用一个框架。当然，这本身并不是问题，你有了一份的工作，一个稳定的。可是，你可能会失去学习的勇气与能力。</p>
<h2 id="持续学习">持续学习</h2>
<h2 id="掌握思想">掌握思想</h2>
<ul>
<li>路由：页面跳转与模块关系</li>
<li>数据：获取与鉴权</li>
<li>数据展示：模板引擎</li>
<li>交互：事件与状态管理</li>
</ul>
<h2 id="后端技能">后端技能</h2>
<p>阅读后端代码的能力</p>
<h1 id="软技能">软技能</h1>
<p>原本打算写一些时间管理，及</p>
<p>篇幅所限</p>
<h2 id="知识管理">知识管理</h2>
<p>将输入的知识变为输出</p>
<p>以输出的方式来输入。</p>
<h2 id="debug-发现问题">Debug: 发现问题</h2>
<p>编程时，我们大部分时候都是在解决问题，即求解已知的问题。</p>
<p>除此，我们还需要花费很多的时间在 Debug 上，即如何去发现问题所在。</p>
<p>最后，如果仍然不能解决问题，那么就找个人、地方提问吧。</p>
<h1 id="扩展篇">扩展篇</h1>
<h1 id="前端知识体系的广度与深度">前端知识体系的广度与深度</h1>
<h2 id="前端与后台的对比">前端与后台的对比</h2>
<p>后台对于深度要求高，而前端对于广度要求高。</p>
<ul>
<li>用户体验设计</li>
</ul>
<p>前端：用户喜爱的产品</p>
<p>基础 HTML + JS + CSS</p>
<p>广度 -&gt; 用户体验、浏览器差异 -&gt; 知识碎片</p>
<p>jQuery + Backbone + xxx</p>
<p>后台：高并发高可用</p>
<p>纠结于 事务一致 锁</p>
<p>Spring + Mybatis + Flyway</p>
<p>数据库 + ORM + MVC</p>
<p>论技术上的深度，自然是后台更深</p>
<p>论用户体验上，自然是前端更深 两种很难衡量</p>
<p>常见问题：Ops 运维 -&gt; 环境问题</p>
<p>对于前端来说，广度 First -&gt; 深度。熟悉框架的相似之处，并且完成任务。</p>
<p>对于后端来说，选定语言，基本上就已经选好一切了，Java -&gt; Spring，Scala -&gt; Play，Ruby -&gt; Rails</p>
<h2 id="用户体验设计">用户体验设计</h2>
<h2 id="前端的广度">前端的广度</h2>
<p>在中大型规模的公司里，会有建议使用的后台语言，他们也主要使用一个后台语言。因为它已经可以很稳定地运行</p>
<p>除非，旧的语言在应用上存在一些缺陷。或者，正在尝试使用新的技术。</p>
<p>而对于前端来说，如果不能选择使用自己的轮子，那么就会是一片混乱。他们会使用不同的框架，不同的团队都有不同的业务场景。</p>
<h1 id="前端的趋势">前端的趋势</h1>
<figure>
<img src="images/future-stacks.png" alt="未来趋势" /><figcaption>未来趋势</figcaption>
</figure>
<h2 id="微服务与微前端">微服务与微前端</h2>
<blockquote>
<p>对于后台采用微服务架构来说，在一个不同的组成部分中，使用不同的技术栈是一种不错的体验；而对于一个前端团队来说，在同一个系统的使用不同的技术栈就不是一种不错的体验。</p>
</blockquote>
<p>可以使用 Web 存储技术，如 LocalStorage 来转移状态。又或者是诸如 Redux 的方式</p>
<h2 id="bff">BFF</h2>
<h2 id="状态管理">状态管理</h2>
<p>Redux</p>
<h2 id="跨平台">跨平台</h2>
<p>Angular 可以移动应用和桌面Web应用，可是它并没有像 React 有那么广泛的用途。</p>
<p>React、React VR、React Native</p>
<h2 id="ui-生成">UI 生成</h2>
<p>过去有 DreamWeaver 这样的软件，现在也有一些强大的 UI 工具，可以直接将设计转化为代码。</p>
<h1 id="转型前端指南">转型前端指南</h1>
<p>职业转型，放弃你现在的工作、相关行业经验，进入一个“新的环境”。这就意味着，当你想转到前端时，你需要面临一系列的挑战。你的老板并不会关心你的过程是怎样的，只要你能达到当前的能力要求，并有能力适应未来的变化即可。</p>
<blockquote>
<p>跳槽穷半年，转行穷三年。</p>
</blockquote>
<p>在过去的两三年里，随着前端领域的火热，市场上有越来越多的、不同行业的人加入了前端大军。人们出于不同的目的，选择上了前端开发。</p>
<p>有的是，大学里喜欢上前端这个行业，在找工作的时候，便选择了相应的岗位；有的是，不喜欢传统的编译型语言，如电子信息工程；有的是，大学上的专业找不到合适的工作，诸如数学等，并且有些专业与编程相比，拥有同等的逻辑能力要求；有的是，看前端行业很赚钱，便报了个培训班，来到了这个行业。</p>
<p>前端这个职业吧，入门快，上手也简单。简单的网页吧，拉上几个初学者便也能完成。可一旦遇上复杂的前端应用，就会暴露出各种各样的问题。于是，那些原先由非编程领域转行过来的人，便容易招至不满。</p>
<p>究其原因吧，是因为能力上达不到要求。我们到是可以看看，有多少人会转向人工智能，下一个行业热点。</p>
<h2 id="改变">改变</h2>
<p>一点点慢慢改变，时间长，成本高，但是痛苦小</p>
<p>主要问题：</p>
<ul>
<li>生活压力</li>
<li>经济来源</li>
</ul>
<p>change -&gt; 改变 -&gt; 痛苦</p>
<ol type="1">
<li>实验 -&gt; 尝试写代码 -&gt; 意义</li>
<li>培训或者 workshop</li>
<li>人脉 &lt;-&gt; 相似的人</li>
<li>意义 &lt;-&gt;</li>
</ol>
<p>编程世界，比现实世界简单，有严格的对错。</p>
<p>如果你是一个没有编程经验的新手，那么你应该去报一个培训班。他可以在短期内帮你提高技术，但是与之相对应的，会带来一些问题。培训机构出来的学员，都存在一定的简历造假。由于数量众多，质量上参差不齐，导致人们普遍对培训机构出来的学员，存在一定的能力怀疑。说到底，你只能把培训机构当成一个入门，它距离你找到一份工作，还有相当大差距。</p>
<p>但是，你是真心的喜欢编程这个职业吗？</p>
<p>我见过一些后来者，他们在开始的时候问一些愚蠢的问题，慢慢的他们意识到这些问题，都是自己搜索就能解决的。他们会加入一些小组，来提高自己。建立一些信心，并去回答一些别人的问题。</p>
<h2 id="后台转前端的挑战">后台转前端的挑战</h2>
<p>Angular 2 -&gt; 是一个不错的选择</p>
<ul>
<li>强类型语言 TypeScript</li>
<li>依赖注入等等的设计模式思维</li>
</ul>
<p>唯一遗憾的是，它不使用 XML 来配置</p>
<p>Node.js 应用也是一个不错的选择</p>
<h2 id="其他编程领域转前端">其他编程领域转前端</h2>
<p>移动端到 React Native，再到 React</p>
<h2 id="其他行业转前端">其他行业转前端</h2>
<h3 id="劝退">劝退</h3>
<p>编程并不是一件容易的事，如果你有业余兴趣便还好，如果没有的话，就算了。</p>
<p>主要原因：它并不是一个赚钱的行业，你是在时间换金钱。。</p>
<p>不妨考虑，投资，或者产生一个千万级的 idea，再找个风投</p>
<p>万一，你又一次选错行了呢？</p>
<h3 id="立意已决">立意已决</h3>
<p>首先，打开浏览器、下载 IDE、然后写一行 HTML 试一试</p>
<p>简单的入门书，如 Head First HTML</p>
<p>找一个小的项目</p>
<ul>
<li>成功的复制一些小网站到本地</li>
<li>然后，再是模拟一些小的项目</li>
</ul>
<ol type="1">
<li>不要预期薪水可以达到市场水平。没有人关心你是谁，你只要能干活，并且小公司、外包公司可能是一个更简单的入门。</li>
</ol>
<p>外包公司 -&gt; 门槛低 -&gt; 相对比较多的成功案例</p>
<p>寻找合适的工作 -&gt; 起步类型</p>
<p>查看相应类型的工作，看看工作介绍</p>
<p>事实上，按照『技术成熟曲线』理论，前端正在进入低谷期。而人工智能才是，现在，乃至未来一段时间的 IT 高薪领域。</p>
<figure>
<img src="images/gartner-hype-cycle.png" alt="Gartner 技术成熟曲线" /><figcaption>Gartner 技术成熟曲线</figcaption>
</figure>
<p>如果你真的喜欢前端，那么：Just do it!</p>
<p>如果你爱请深爱~。</p>
<h1 id="前端跨行指南">前端跨行指南</h1>
<p>JavaScript 应用领域</p>
<p>挑战：要学会新的领域的知识，以及其对应的语言知识。如开发混合应用时，在 iOS 方面，你需要有些许 Objective-C 或者 Swift 的开发能力，在 Android 方面，你还需要些许的 Java 经验。</p>
<h2 id="移动开发混合开发">移动开发：混合开发</h2>
<h2 id="桌面应用">桌面应用</h2>
<h2 id="vr">VR</h2>
<h2 id="硬件">硬件</h2>
<h2 id="其它">其它？</h2>
<section class="footnotes">
<hr />
<ol>
<li id="fn1"><p>颇受欢迎的个人电脑厂商奥斯本，其公司的创新式便携电脑还没有上市，就宣布他们要推出的更高档的机器，而又迟迟无法交货，消费者闻风纷纷停止下单订购现有机种，最后导致奥斯本因收入枯竭而宣布破产。<a href="#fnref1">↩</a></p></li>
</ol>
</section>
</body>
</html>
